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REMARKS 



By this Preliminary Amendment originally-filed claims 1-14 have been 
cancelled and replaced with the new claims 15-28 which are believed to place 
the claims in better form for consideration upon examination. No new matter has 
been added. 

The amendments to the original specification are provided to address 
grammatical and syntactical errors in the translation of the original German 
language specification. No new matter has been introduced into the application. 

The amendments to the "Claims" and "Abstract" are reflected in the 
attached "Version With Marked Changes Made." 

Favorable consideration and allowance of the claims are respectfully 

requested. 

Respectfully submitted, 
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Version With Marked Changes Made 

WE CLAIM: 

1 . 253^254 15 A method of operating 25J W 56 § 

programmed industrial controller equipped with a runtime system 257 i n particular 
for 258 ^ production 259 mach i n e s, wh e r ei n m e chanisms wh i ch e nab le 260 machine 
comprising the steps of 

checking for occurrence of a 261 us e r to wa i t 262 desired 
condition in the 263 program flow 264 operation of the machine. 

stopping the program flow of the machine operation while 
checking for 265 anv 266 the occurrence of said desired 267 cond i t i on are prov i d e d, 
the — program — flow — b e ing — i mm e d i ately cont i nu e d — wh e n — the — condit i on — is 
satisfi o d 268 condition and 269 the program flow b oi ng stopped wh o n th e cond i t i on i s 
not satisfied, unt il i t is estab li shed that the cond i t i on has boon satisfi e d . 270 waiting 
for said condition to occur. 

increasing the priority of 271 the-checking for the 272 desired 
condition 273 b o ing incr e as o d i n compar i son with 274 relative to the current task 
priority 275 white wait i ng fer 276 ^ the program flow. and 

immediately continuing the program flow upon satisfaction of 
the condition 277 to bo satisf i ed . 

2. 278 2^ 279 ^The method according to claim 2 *% 28 '^ 
wherein once the condition has been satisfied, the following program sequence 

NY02:357643.1 

8 



A34488 (071308.0211) 
PATENT 

is processed with high priority up to an explicit end, the old task priority being 
resumed after the explicit end of the program sequence. 

3. 282^283 1 7 The method according to claim 284 4r 285 l^ 
wherein process signals and/or internal signals of the controller and/or variables 
from user programs are used for the formulation of the conditions. 

4. 286 4r _287 1 8> The method according to claim 288 4 7 289 15 ft 
wherein the conditions contain logical and/or arithmetic and/or any desired 
functional combinational operations. 

5 290^291 19 The method according to claim 292 4 7 293 15 ft 
wherein 294 a 295 the user program for the operation of the controller 296 contains 297 j§ 
capable of responding in the mann er set forth more than one such 
298 m e chan i sm 299 condition . 

6. 3oo^3oi 2Q The method according to claim 30 % Z0Z 1Zl 
wherein 304 i n th e op e rat i on of th e controll e r, there 305 mav-ke 306 are provided for 
the controller, a plurality of user programs which 3Q7 conta i n — th e s e 
m e chan i sms 308 operate in the manner set forth . 

7. 309^_3io 21 The me thod as claimed according to claim 
311 47 312 1^ wherein the 313 r e sp e ctiv e mochan i sm 314 proaram for operating the 
controller is available 315 to a user i n a us e r program as a customary 
programming-language construct. 
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8. 316 g^ 317 22. An industrial controller for carrying out the 
method according to claim 318 4t 319 1JL wherein the runtime system of the 
controller contains a running level model which has a plurality of running levels of 
different types with different priority, 320 th e fo l low i ng 321 sajd running levels 
322 boing providod 323 comprisina : 

a) a group of levels with synchronously clocked levels, 
324 compr i s i na 325 havina at least one system level and at least one user level, 326 -4t 
be i ng poss i bl e for the levels of this group of levels 327 to hav e pr i or i tizina 328 beina 
capable of being prioritized with respect to one another; 

b) a user level for system exceptions; 

c) a time-controlled user level; 

d) an event-controlled user level; 

e) a sequential user level; and 

f) a cyclical user level; 329 
and wherein user levels of the group of levels a) 330 opt i onallv b oi na 331 are able to 
run synchronously in relation to one of the system levels of the group of levels a). 

9. 332q^__333 2 3 The j nc | US trial controller according to claim 
334g_335£2^ wherein the basic clock of the running level model is derived from 
336 anv one of an internal timer 337 or from 338 ^ an internal clock of a communication 
medium^-^^om 340 , an external device or 341 from-a variable which belongs to 
the technological process 342 of the machine . 
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10. 343 40t- 344 24. The industrial controller according to claim 
345 g T 346 22. wherein the time-controlled user level, the event-controlled user level, 
the sequential running level, the cyclical background level and the user level for 
system exceptions are optional. 

11. 347 44^ 348 25. The industrial controller according to claim 
349 8t 350 22. wherein the synchronous levels are clocked in relation to the basic 
clock with a step-up and/or step-down ratio and/or in the ratio 1:1. 

12. 351 42t-- 352 26. The industrial controller according to claim 
353g_35422 f wherein further prioritizing stratifications are provided within the 
running levels. 

13. 355 43^ 356 27. The industrial controller according to claim 
357g_358 22 wherein user tasks can optionally be run through during system 
running-up and/or during system running-down. 

14. 359 44^- 360 28. The industrial controller according to claim 
361 8t 362 22 t wherein user programs which, depending on the type of user level, 
are programmed in a cycle-oriented or sequential manner can be loaded into the 
user levels. 
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ABSTRACT OF THE DISCLOSURE 

Mechanisms for operating an industrial controller 363 {S)-equipped with a runtime 
system 364 (RTS) , in particular for production machines, which enable a user to 
wait in the program flow for any desired condition are provided 365 T-the 366 . The 
program flow 367 b e ing 368 j§ immediately continued when the condition is satisfied 
and the program flow 369 b e ing 370 j§ stopped when the condition is not satisfied, 
until it is established that the condition has been satisfied 371 r4be 372 ^JM priority 
of the checking for the condition 373 b ei ng 374 j§ increased in comparison with the 
current task priority while waiting for the condition to be satisfied. When the 
condition has been satisfied, a defined program sequence is processed with high 
priority up to an explicit end, the old task priority being resumed after the explicit 
end of the program sequence. 
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BAKER BOTTS L.L.P. 
30 ROCKEFELLER PLAZA 
NEW YORK, NEW YORK 101 12 



TO ALL WHOM IT MAY CONCERN: 

Be it known that WE, Armin Amrhein, Johannes Birzer, Thomas 

Hennefelder, Martin Kiesel, Raimund Kram and Regina Schmitt, citizens of Germany, 

residing in Kuemmersbruck, Stulln, Sugenheim, Poxdorf, Erlangen and Erlangen 

respectively, whose post office addresses are Dresdnerstr. 16, 92245 Kuemmerstruck, 

Germany; Friedhofweg 2, 92551 Stulln, Germany; Deutenheim 35, 91484 Sugenheim, 

Germany; Jahnstr. 36, 91099 Poxdorf, Germany; Fliederstr. 7A, 91056 Erlangen, 

Germany; and Herbstaeckerweg 5, 91056 Erlangen, Germany; respectively, have 

invented an improvement in: 

3 &S334©D~QF~0P^^ CONTROLLER 4 AND METHOD OF 

OPERATING SAME 

of which the following is a / 

SPECIFICATION 

6 FIELD OF THE INVENTION 
[0001] The invention relates to a method of operating an industrial controller, in 

particular for production machines. 7 The invention alsoF uFtfa®m*efer4he4m t eflfeeft 8 
relates to an industrial controller for carrying out the method according to the invention. 
[0002] 9 FwtheHaefe r the4ra E enti^ to an indu s trial eenfroH er for carrying 

out the metfa®d-fieeeg&ftfr4®-fee4m*@^^ application is related to U.S. Patent 

Application Ser. No. 09/ 938.751. filed August 24. 2 001 bv the present inventors. 
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" BACKGROUND OF THE INVENTION 
[0003] It is customary nowadays, both for stored-program control (SPC) and for 

motion control (MC), to model hierarchical running levels that are different in each case 
and are assigned software tasks for controlling the respective technical process. These 
tasks may perform system functions, but may also be user-programmed. 
[0004] It is known from DE 197 40 550 Al that process control functionalities of 

the stored-program controllers "SPC" and motion functionalities of MC controllers can be 
integrated in a uniform configurable control system. 

[0005] This SPC/MC integration takes place in the form of interconnecting SPC 

and MC control modules. However, when the integration is carried out in such a way, an 
optimum and efficient task structure is not achieved for the entirety of the control tasks. 
Furthermore, with this type of integration it is mainly the classic MC functionalities, as 
are relevant in particular for machine tools, that are supported. Requirements for the 
controller, as they are known from the operation of production machines, are not 
optimally supported by this type of interconnection of SPC and MC control modules. 
[0006] It is known from EP 0 735 445 A2 to use a separate waiting command 

(WAIT) for the operation of a machine tool or a robot. However, the waiting command 
(WAIT) described here still does not optimally support the control of production 
machines in particular. 

[0007] In the application DE 19 93 19 33.2 it is proposed to use the clock of the 

communication system between the PC system and the peripheral devices for a change 
between a real-time operating program and a non-real-time operating program. Here, 
however, it is the task of this clock pickup from the communication system to allow the 
smoothest possible change to take place between real-time and non-real-time applications 
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in an industrial process. In this configuration, the basic clock is only derived however 
from the clock of the communication medium and it is only used for the changing of the 
operating system mode of a PC system. 

" SUMMARY OF THE INVENTION 
[0008] The invention 14 is-therefore 15 based on the 1 6 has as its object 17 ef* 8 the 

19 or e ating 2Q creation in a simple manner 21 of an industrial controller 22 with optimum 
distinctive characteristics 23 of an industrial oontroll e r for 24 in each oase different control 
tasks and different boundary conditions or requirements of the underlying technical 
process, the controller providing both SPC and MC functionality and consequently also 
being suitable for the control of production machines. 

[0009] These optimum distinctive characteristics are achieved in principle on the 

one hand by a uniform configurable running level model for the control tasks of the 
industrial controller and on the other hand by mechanisms f 26 e.g.. wait for condition 
27 oommand 2 8 commands > > which enable a user to wait for any desired conditions and 
respond with higher priority in the program flow. 

[0010] Setting out from this approach, the object stated above is achieved by 

providing mechanisms which enable a user to wait in the program flow for any desired 
condition, the program flow being immediately continued when the condition is satisfied 
and the program flow being stopped when the condition is not satisfied, until it is 
established that the condition has been satisfied, the priority of the checking for the 
condition being increased in comparison with the current task priority while waiting for 
the condition to be satisfied. This mechanism makes it possible to express a unified and 
closed task definition in a piece of code of a user program without further mechanisms, 
such as for example event handlers, being required. A user can consequently formulate 
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the waiting for high-priority events in a sequential program sequence on a relatively low 
priority level of a "motion task" by program constructs in his program flow (user 
program), without having to change into another program. This on the one hand avoids a 
management overhead in the controller, which directly enhances the system performance, 
and on the other hand supports the locality principle from a programming viewpoint, as a 
result of which, for example, debugging is made easier. 

[0011] The mechanism described and the associated command are referred to 

hereafter as the "waitforcondition". 

[0012] A first advantageous refinement of the present invention is that, once the 

condition has been satisfied, the following program sequence is processed with high 
priority up to an explicit end, the old task priority being resumed after the explicit end of 
the program sequence. As a result, high deterministics are achieved in the sequence 
"waiting for external event" and the "action which follows this event", for example 
corrective movements in the case of printed mark synchronization. A user consequently 
has the possibility of temporarily switching to a high priority level in his programs and 
thereby being able to describe deterministic processes easily and elegantly. Application 
examples are, for example, printed mark synchronization and a rapid start of movement 
(for example after an edge change). 

[0013] A further advantageous refinement of the invention is that process signals 

and/or internal signals of the controller and/or variables from user programs are used for 
the formulation of the conditions. This makes it possible for the user when describing the 
conditions to use not only user program variables but also directly system states and 
process signals in a uniform way. 
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[0014] A further advantageous refinement of the invention is that the conditions 

contain logical and/or arithmetic and/or any desired functional combinational operations. 
It is consequently possible for the user to specify complex synchronization relationships 
within an instruction. 

[0015] A further advantageous refinement of the invention is that a user program 

for the operation of the controller contains more than one such 29 wait-for mechanism. As 
a result, the flexibility and possibilities for the user, in particular with regard to the 
description of synchronization activities, in the programming of the applications are 
increased. 

[0016] A further advantageous refinement of the invention is that, in the operation 

of the controller, there may be a plurality of user programs which contain these 30 wait-for 
mechanisms. As a result, the flexibility and possibilities for the user, in particular with 
regard to the description of synchronization activities in the programming of the 
applications are increased. 

[0017] A further advantageous refinement of the invention is that the respective 

31 wait-for mechanism is available to a user in a user program as a customary 
programming-language construct. The "waitforcondition command", which triggers 
this mechanism, can consequently be used by a user in the user programs, for example 
like a while loop, whereby the programming is made very much easier. 
[0018] A further advantageous refinement of the invention is that the runtime 

system of the controller contains a running level model which has a plurality of running 
levels of different types with different priority, the following running levels being 
provided: 
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belongs to the technological process allows direct feedback from the technological 
process to the controller to be obtained in a very easy way. 
[0021] A further advantageous refinement of the invention is that the time- 

controlled user level, the event-controlled user level, the sequential running level, the 
cyclical background level and the user level for system exceptions are optional. As a 
result, the user can very flexibly create for himself a controller which is very efficient for 
his actual requirements and which contains the running levels required at the specific 
time, and consequently does not include any unnecessary overhead. 
[0022] A further advantageous refinement of the invention is that the synchronous 

levels are clocked in relation to the basic clock with a step-up and/or step-down ratio 
and/or in the ratio 1:1. As a result, the levels can in each case be clocked very easily to a 
multiple of the basic clock or else be clocked in each case to a reciprocal multiple. On 
the basis of a common starting variable, step-up ratios or else step-down ratios can 
consequently be achieved very easily for the respective levels. 
[0023] A further advantageous refinement of the invention is that further 

prioritizing stratifications are provided within the running levels. As a result, the 
software structure of the industrial controller can be adapted optimally to the different 
control tasks or to the requirements of the underlying technical process. Consequently, 
for example, different causes of faults can be assigned to different levels, with 38 ft for 
example 39 ^ ascending priority. 

[0024] A further advantageous refinement of the invention is that user tasks can 

optionally be run through during system running-up and/or during system running-down. 
This allows, for example, initialization functions to be 4 0 initiated 4 1 started during system 
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a) a group of levels with synchronously clocked levels, comprising at 
least one system level and at least one user level, it being possible 
for the levels of this group of levels to have prioritizing with 
respect to one another; 

b) a user level for system exceptions; 

c) a time-controlled user level; 

d) an event-controlled user level; 

e) a sequential user level; 

f) a cyclical user level, user levels of the group of levels a) optionally 
being able to run synchronously in relation to one of the system 
levels of the group of levels a). 

[0019] A major advantage of this stratification is that the communication between 

the tasks of the process controller (SPC) and those of the motion controller (MC) is 
minimized. A further advantage is that the programming of the control tasks for the 
process controller and for the motion controller can take place in a uniform programming 
language with a uniform creation interface and that the user can flexibly create a running 
level model tailor-made for his respective requirements. 

[0020] A further advantageous refinement of the invention is that the basic clock 

of the running level model is derived from 32 anv of an internal timer 33 or from 34 , an 
internal clock of a communication medium 35 or from 36 t an external device or 37 from a 
variable which belongs to the technological process. As a result, the basic clock for the 
running level model can be derived in a very flexible and very easy manner. The fact that 
the basic clock for the running level model can also be derived from a variable which 
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running-upor it-to b e e nsur e d ensure during system running-down that the axes 
present in the system assume a defined position. 

[0025] A further advantageous refinement of the invention is that user programs 

which, depending on the type of user level, are programmed in a cycle-oriented or 
sequential manner can be loaded into the user levels. This allows the user to adapt the 
functionality of the controller very flexibly to the underlying requirements of the 
technical process in his user programs and also allows him to load the user programs into 
different user levels, in order in this way to achieve distinctive characteristics of the 
controller that are effective for his respective applications. A further advantage is that the 
user can load both cycle-oriented user programs and event-oriented user programs into a 
uniform running level model or runtime system of an industrial controller. A user can 
consequently additionally load programs programmed according to different paradigms 
(cycle-oriented for SPC functionality and event-oriented or sequentially for motion 
functionality) very flexibly and conformally into the user levels of the running level 
model. 

45 BRIEF DESCRIPTION OF THE DRAWINGS 
[0026] An exemplary embodiment of the invention is 46 e xplain e d 4 7 described 

below 48 and r e pr e s e nt e d in 49 coniunction with t he 50 drawing 51 appended drawings , in 
which: 

52 gjgufe 53 Eiit 1 shows the main running levels of a classic stored-program 

controller; 

54 figuFe 55 Fig. 2 shows the main running levels of a motion controller; 
56 £jgure 57 Ei&. 3 58 shews 59 is a schematic representation of an industrial 

controller; 
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Figur e Fie. 4 shows the running level model of the industrial controller 
according to the invention; 

62 F*gwe 63 Fig. 5 shows an exemplary embodiment of the loading of user 
programs into the user levels; 

^Ftgwe^ Fig . 6 shows an exemplary embodiment of the use and 
mechanism of the wait for condition command in the running level model of the 
industrial controller according to the invention; 

^Figure^ Fig. 7 shows a further exemplary embodiment of the use and 
mechanism of the wait_for_condition command in the running level model of the 
industrial controller according to the invention; 

^Ftgure^Eig. 8 shows the syntactic description of the wait_for_condition 
command in a syntax diagram; 

7Q Fjgwe 71 Fip. 9 shows an example of the formulation of an expression in 
programming-language notation; and 

72 F*gtge 73 Fift . 10 shows in a schematic representation possibilities for 
74 hew 75 obtaininp the basic clock 76 is obtain e d for the industrial controller. 

" DETAILED DESCRIPTION OF THE INVENTION 
[0027] In 78 th e r e pr e s e ntation according to Figur e 79 Fig. 1 , the main running levels 

of a classic stored-program controller (SPC), arranged according to their priority, are 
shown. The increase in priority is symbolized there by 8Q ftf» 81 the upwardly pointing 
arrow. In the lowest-priority level, 82 as indicat e d by a dash e d lin e , t wo different tasks are 
performed, 83 to b e sp e oifio ^ as indicated by the dashed line. Specifically r these are a free 
cycle, i.e 85 ft "user level free cycle 1 ' and a background system level, i.e. 86 4 "system level 
background". The background system level is assigned, for example, communication 
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tasks. In a following user level, referred to as "user level time-controlled", Jhe 
parameters for the calling clock of the tasks or of the programs of this level can be 
parameterized. Monitoring takes place to ascertain whether the processing of a user 
program of this clocked level has been completed in time before the start event occurs 
once again. If the clock time elapses without the user program of the assigned level 
being processed to completion, a corresponding task of a next-but-one, in priority terms, 
"user level for asynchronous faults" is started. In this "user level for asynchronous 
faults", the user can program out the handling of fault states. 

[0028] The "user level time-controlled" is followed by a "user level events". The 

response to external or internal events takes place within the "user level events". A 
typical example of such an event is the switching of a binary or digital input, whereby 
typically an event is triggered. In a "system level high priority" lie the tasks of the 
operating system which ensure the operating mode of the programmable controller 
(SPC). 

[0029] The representation according to 88 £*gure 89 Fig. 2 shows the main running 

levels of a motion controller (MC). Here, too, the individual levels are arranged 
hierarchically according to their priority, as symbolized by ^ea^ the upwardly arrow. A 
"system level background" and a "user level sequential" have an equal priority, that is the 
lowest priority. This unified nature in terms of tasks is symbolized as in 92 ftgwe 93 Fig. 1 
by a dashed line. The tasks of the "user level sequential" are processed together with the 
tasks of the "system level background" in the round-robin procedure. Typical tasks of the 
"system level background" are, for example, those for communication task. In the "user 
level sequential", the parts of the program programmed by the user run for the actual 
control task. If, in one of these parts of the program, the controller encounters a 
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movement or positioning command, a "suspend" is set, i.e. 94 ft the user program is 
interrupted at this point. In this case, a command is synchronously used. The processing 
of this movement or positioning command take place in a highest-priority "system level 
clocked". Each and every position controller or interpolator which is running in the 
"system level clocked" executes this movement or positioning command. After 
execution of the command, control returns to the "user level sequential" and the user 
program interrupted by "suspend" is continued by a "resume" at the same point. The 
"system level clocked" contains not only the already mentioned position controllers but 
also the interpolation part of the control. 

[0030] The "user level events" resumes at the lowest-priority level. 

Accommodated here are those tasks which respond to external or internal events. Such 
events may be alarms, for example. 

[0031] In a following "user level synchronously clocked", synchronously clocked 

user tasks are performed, for example controller functionalities. These tasks are 
synchronized in relation to clocked system functions, such as for example the 
interpolator, position controller or cyclical bus communication. 
[0032] In 95 th e r e pr e s e ntation according to Fieur e 96 Fig. 3, 97 it 98 there is shown 99 ft 

in the form of a 1Q Q block structure diagram 101 t that the control of a technical process PI is 
performed by means of the runtime system RTS of an industrial controller. The 
connection between the runtime system RTS of the controller and the technical process 
PI takes place bidirectionally via the inputs/outputs EA. The programming of the 
controller, and consequently fixing the behavior of the runtime system RTS, takes place 
in the engineering system ES. The engineering system ES contains tools for configuring, 
project planning and programming for machines or for controlling technical processes. 
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The programs created in the engineering system are transferred via the information path I 
into the runtime system RTS of the controller. With respect to its hardware equipment, 
an engineering system ES usually comprises a computer system with graphics screen 
( 102 for e xampl e display), input aids (for example 103 ^ keyboard and mouse), processor, 
main memory and secondary memory, a device for accepting computer-readable media 
(for example 104 ^ floppy disks, CDs) and also connection units for data exchange with 
other systems (for example l05 ft further computer systems, controllers for technical 
processes) or media (for example 106 ft the Internet). A controller usually comprises input 
and output units, and also a processor and program memory. It is also conceivable for the 
control of a technical process PI to be performed by means of a plurality of runtime 
systems RTS of industrial controllers. 

[0033] The representation 107 aooording to Figur e 108 of Fie. 4 shows the running 

level model of the industrial controller 109 according to the invention . The prioritizing of 
the levels is indicated by 110 an in |hg arrow m pointing upwardly in the direction of the 
highest priority. The lowest-priority levels are the "cyclical user level" and the 
"sequential user level". These two levels run with the same priority. Therefore, these 
levels are separated in the representation according to 113 Figwe n4 EijL 4 by a dashed line. 
The "cyclical user level" includes the "background task", which is cycle-time-monitored. 
In the "sequential user level", the "motion tasks" are run through. "Motion tasks" are not 
cycle-time-monitored and serve essentially for describing sequential sequences. "Motion 
tasks" are processed virtually in parallel. Generally, all the user levels contain one or 
more tasks. The tasks receive the user programs. The tasks of the "cyclical user level" 
and of the "sequential user level" are processed in a common round-robin cycle. 
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[0034] The next-following level is the "time-controlled user level". The tasks of 

this level are activated in a time-controlled manner. The time control can be set in a 
1 ^granularity 1 16 scale of milliseconds. The "time-controlled user level" is followed by the 
"event-controlled user level". In this level, after detection of a user interrupt, what are 
known as "user interrupt tasks" are activated. User interrupt events may be formulated as 
a logical combination of process events and/or internal states. 
[0035] The next-higher level is the "user level for system exceptions". In this 

"user level for system exceptions", monitoring U7 of system interrupts is carried out II8 -ef 
s yst e m int e rrupts, th e 119 . The occurrence of 120 wyeh 121 svstem interrupts has the effect of 
generating what are known as "exceptions", i.e. 122 4 instances of handling exceptional 
cases. In the "user level for system exceptions" there are, for example, the following 
tasks, which are activated when a corresponding system interrupt occurs: 

a) "time fault task", which is activated when time monitors respond; 

b) "peripheral fault task", which is activated for example in the event 
of process and diagnosis alarms, but also in the event of station 
failure or station return; 

c) "system fault task", which is activated in the event of general 
system faults; 

d) "program fault task", which is activated in the event of 
programming faults (for example division by zero); 

e) "time fault background task", which is activated when the cycle 
time monitoring of the background task responds; and 

f) "technological fault task", which is activated in the event of 
technological faults. 
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[0036] Following next is the group of levels "synchronously clocked levels". 

This group of levels has the highest priority in the running level model. The individual 
levels of this group of levels may 123 have 124 b§ further 1 25 prioritizinps 1 2 6 prioritized with 
respect to one another. The group of levels "synchronously clocked levels" comprises at 
least one system level and at least one user level The system levels include the system 
functions such as, for example, position controller or interpolator. User programs (API - 
AP4; 127 FjgtH=e 128 Fiff. 5) can be flexibly loaded in addition by a user into the user levels of 
this group of levels. 

[0037] For the clock control of the "synchronously clocked levels" there are a 

129 seFtes 13 0 number of different possibilities for clock generation. The basic clock may 
come, for example, from an internal timer (Tl; 131 F*gure 132 Fiq. 10) or from an internal 
clock (T3; 133 Fiewe 134 Fig. 10) of a communication medium (for example Profibus) or 
else the clock may also be derived from a process event of the technological process. 
Such a process event may be, for example, the clock rate (TG; 135 F4gtge 136 Eig,. 10) of an 
operation on a production machine or packaging machine. User levels of the group of 
levels "synchronously clocked levels" may in this case be clocked on the basis of the 
basic clock, but they may also run synchronously in relation to one of the system levels 
of the group of levels "synchronously clocked levels". The user tasks of this user level 
synchronous to a system level consequently have a synchronous, i.e. 137 4 deterministic, 
relationship with a system level which can be flexibly fixed by the user. This has the 
advantage that deterministic responses to system tasks (system tasks run in the system 
levels) which the user has programmed in his user tasks, which run in the user levels of 
the group of levels "synchronously clocked levels", are guaranteed by the system. That is 
to say, for example, that the system guarantees that this "synchronous user level" is 
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correspondingly activated for example before the interpolator, or else before any other 
desired system function. 

[0038] The "time-controlled user level", the "event-controlled user level", the 

"sequential user level", the "cyclical user level" and the "user level for system 
exceptions" are optional. 

[0039] The task of the "cyclical user level" (background task) is cycle-time- 

monitored. The "motion tasks 11 , on the other hand, are not cycle-time-monitored and 
serve essentially for describing sequential sequences. That is to say the present running 
level model supports a user both in the programming of sequential sequences and in event 
programming. Consequently, synchronous events and asynchronous events can be 
covered by the programming. The user programs (API - AP4; 138 F*gwe 139 Fig. 5) created 
by the user can be loaded in addition into the user levels. The user programs API to AP4 
are usually created with the aid of a programming environment of the engineering system 
fES: 140 -ftgur^ 141 Fig. 3\ 

[0040] 142 The r e presentation according to figure 143 Ei& 5 144 shews 145 illustrates an 

exemplary embodiment of the additional loading of user programs into the user levels. 
146 gjgttfe 147 Fig. 5 shows by way of example distinctive characteristics of user levels of 
the running level model. 148 ft-*s 149 As shown by the three 150 peiftts 151 bold dots at the 
lower edge of the drawing 152 4hat 153 4 there may also be still further user levels, or else 
system levels. The prioritizing of the levels is indicated as above by 154 an 155 lhe arrow 
156 pointinp upwardly in the direction of the highest priority. The user levels are assigned 
the user programs API to AP4, indicated at the right-hand edge of the figure by small 
squares. The assignment is shown by assignment arrows ZP1 to ZP4. In the user levels 
157 1 to 4 t here are tasks which receive the additionally loaded user programs API to 
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AP 158 4r 15 9 4. respectively. These tasks are then run through or processed in accordance 
with a specific strategy (for example sequentially). They may continue to have the 
property that they are run-time-monitored. 

[0041] 16Q The repr e s e ntation according to Figur e 161 Ei& 6 shows an exemplary 

embodiment of the use and mechanism of the waitforcondition command, in the 
running level model of the industrial controller according to the invention. The 
wait_for_condition command (represented in 162 Fjg«re 163 Fig. 6 as wait_for_cond()) is 
used by way of example in this representation in the "sequential user level 11 . The 
waitforcondition command is used in the "motion tasks" MT1 and MT2 created by the 
user, which are a component part of the "sequential user level". The "motion tasks" MT1 
and MT2 are in a round-robin cycle, represented by the arrow from MT1 to MT2 and by 
the 164 angl e d - awav 165 looping return arrow from MT2 to MT1 . The three 166 points insid e 
this 167 bold dots in the return arrow indicate that there may be still further "motion tasks" 
in the round-robin cycle. The "motion task" MT1 contains the wait for condition 
command "wait_for_cond(cond_l)", the "motion task" MT2 contains the 
wait for condition command "wait_for_cond(cond_2) n . 168 Thr ee points us e d 16 9 The bold 
dots included in each case within MT1 and MT2 indicate that, in addition to the two 
wait_for_condition commands and the three positioning commands posl() to pos3(), still 
further commands may be contained in the "motion tasks". 

[0042] Altogether, the running level model, represented by way of example in 

17Q Fjg*ffe- 171 Fig. 6. of a runtime system for an industrial controller comprises the 
following levels (enumeration from the lowest to the highest priority): "cyclical user 
level", "sequential user level" (the tasks of these two levels have the same priority, 
represented by the dashed line between these levels), "time-controlled user level", "event- 
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controlled user level", "user level for system exceptions", "synchronously clocked user 
level 2", "synchronously clocked user level 1", "synchronously clocked system level 2" 
and, as the highest-priority level, a "synchronously clocked system level 1". 
[0043] The operating mode of the wait for condition command is shown by way 

of example by "wait_for_cond(cond_l)" from the "motion task" MT1. If the "motion 
task" MT1 is next in turn in the round-robin cycle, the commands of the "motion task" 
MT1 are serviced until the time slice has elapsed, or an interruption occurs. If this is the 
case, the "motion task" MT2 is serviced as the next task in the cycle, etc. If the 
wait for cond(cond l) command is processed in the "motion task" MT1, the condition 
condl is checked. If condl = true, that is to say is satisfied, the next-following 
command pos2() is immediately executed and, if appropriate, further commands present 
in MT1 are successively processed, until control is passed to the next task. 
[0044] If the condition cond l = false, that is to say is not satisfied, the "motion 

task" MT1 is immediately interrupted and MT2 is serviced in the round-robin cycle. The 
condition cond_l is inserted, however, into the "synchronously clocked system level 2" 
(indicated by the solid 172 angl e d awav 173 line arrow from the wait_for_cond(cond_l) 
command to the "synchronously clocked system level 2") and is checked in the clock 
cycle of this system level to ascertain whether it has been satisfied. If the condition 
cond l is satisfied, the current task is displaced in the round-robin cycle, i.e. 174 4 it has the 
time slice withdrawn from it and the motion task MT1 is continued immediately after the 
wait_for_cond(cond_l) with the positioning command pos2(). The return from the 
"synchronously clocked system level 2" to the positioning command pos2(), i.e. 175 t to the 
"sequential user level", is indicated by the dashed line arrow. 
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[0045] The fact that, when the condition of the wait_for_condition command has 

not been satisfied, the checking for the condition takes place in a high-priority 
"synchronously clocked system level" and, when the condition has been satisfied, the 
interrupted "motion task" is continued immediately 177 ^ makes it possible for a user to 
specify extremely time-critical applications by simple language means during the 
programming of sequences of movements. The performance and deterministics are 
further enhanced by only inserting and considering currently applicable conditions when 
checking the conditions in the respective high-priority "synchronously clocked system 
levels". 

[0046J The mechanism described here also does not require an explicit event 

handler. 178 ¥he 179 ConseQuentlv. the great advantage from the user viewpoint is 
^ cons e qu e ntly t hat the user can now formulate high-priority events in a sequential 
running program on a relatively low priority level of a "motion task" in his program flow 
with the aid of program constructs, and does not have to change into another program 
which he then has to project by means of other mechanisms (for example manually or 

181 182 183 

under interrupt control) onto a synchronous user task . Instead , but |hg 
184 jftstead 185 user has the possibility in a closed user program of formulating this "waiting 
for high-priority event" and "high-priority reaction" cycle for this event in a program on a 
closed basis. 

[0047] The conditions which are inquired in a wait for condition command can 

be formulated very flexibly and elegantly by the user. For instance, for formulating these 
conditions, the user can use program variables from a user program or internal variables 
of the controller, or he can also reference process signals. These variables may then be 
combined logically, arithmetically or by any desired functions in terms of their content, 
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to formulate a condition from them. In addition to the high-priority inquiries as to 
whether the condition is satisfied, it is also conceivable that, if the condition is satisfied, a 
program code belonging to it, i.e. fi an underlying response, which is user- 
programmable, is also executed with high priority 187 T-Aftd 188 that 189 and the return to the 
low-priority level only takes place after execution of this program code. 
[0048J The representation according to 19Q F*gwe 191 Fi fl. 7 shows an extended 

exemplary embodiment of the use and mechanism of the wait_for_condition command, 
in the running level model of the industrial controller according to the invention. The 
waitforcondition command (in 192 FieuFe 193 Fig. 7 likewise represented as 
wait for_cond()) is used by way of example in this representation in the "sequential user 
level". The wait for condition command is used in the "motion tasks" MT3 and MT4 
created by the user, which are a component part of the "sequential user level". The 
"motion tasks" MT3 and MT4 are in a round-robin cycle, represented by the arrow from 
MT3 to MT4 and by the 194 angl e d awav 195 looping return arrow from MT4 to MT3. The 
three 196 points insid e this 197 bold dots in the return arrow indicate that there may be still 
further "motion tasks" in the round-robin cycle. The "motion task" MT3 contains the 
wait for condition command "wait_for_cond(cond_3)", the "motion task" MT4 contains 
the wait for condition command "wait_for_cond(cond_4) n . 198 Thr ee points us e d 199 lhg 
bold dots included in each case within MT3 and MT4 indicate that, in addition to the two 
wait for condition commands and the positioning commands pos4() to pos8(), still 
further commands may be contained in the "motion tasks". The programming-language 
constructs "wait_for_cond()" and "end_wait_for_cond" have the effect of bracketing a 
program sequence in the "motion tasks". In the "motion task" MT3, the commands 
pos5() and pos6() are bracketed in this way. The use of "wait_for_cond()" and 
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"end_wait_for_cond" is also indicated in the "motion task" MT4. It is schematically 
indicated by 3 200 BeHrts 201 bold dots in each case in the "motion task" MT4 that further 
instructions may be present before, within and after the "wait_for_cond() - 
end_wait_for_cond" construct. 

[0049] The running level model, represented by way of example in 

2Q2 ftgufe 203 Fig. 7, of a runtime system for an industrial controller comprises, as in 
204 ftguFe 205 Fig. 6, the following levels (enumeration from the lowest to the highest 
priority): "cyclical background level", "sequential user level" (the tasks of these two 
levels have the same priority, represented by the dashed line between these levels), 
" 2Q6 eveftt 207 time-controlled user level", " 208 tefte 20 9 event -controlled user level", "user level 
for system exceptions", "synchronously clocked user level 2", "synchronously clocked 
user level 1", "synchronously clocked system level 2" and, as the highest-priority level, a 
"synchronously clocked system level 1". 

[0050J In 210 figttfe 211 Fig. 7, the operating mode of the wait_for_condition 

command with an associated program sequence is shown by way of example as 
wait_for_cond(cond_3)" from the "motion task" MT3. The checking of the condition 
cond_3 and the processing of the associated program sequence (bracketed between 
"wait_for_cond(cond_3) !f and "end_wait_for_cond") take place in this case on a higher- 
priority level of the running level model. The program sequence belonging to 
"wait_for_cond(cond_3) n is formed by the sequence of the commands pos5() and pos6(). 
[0051] If the "motion task" MT3 is next in turn in the round-robin cycle, the 

commands of the "motion task" MT3 are serviced until the time slice has elapsed, or an 
interruption occurs. If this is the case, the "motion task" MT4 is serviced as the next task 
in the cycle, etc. If the "wait_for_cond(cond_3)" command is processed in the "motion 

COMPARISON 

NYO^fcttMQ^W.MO 7 -20- 



^34488-071308.0211 



task" MT3, the condition cond_3 is checked. If cond_3 = true, that is to say is satisfied, 
the normal program sequence is continued, i.e. 212 4 the command pos5() is executed next 
and, if appropriate, further commands present in MT3 are successively processed, until 
control is passed to the next motion task. 

[0052] If the condition cond_3 = false, that is to say is not satisfied, the "motion 

task" MT3 is immediately interrupted and MT4 is serviced in the round-robin cycle. The 
condition cond_3 and the commands pos5() and pos6() (as the associated program 
sequence) are processed in the priority of the "synchronously clocked system level 2" 
(indicated by the solid 2 1 3 angl e d - awav 2 14 line arrow, starting from the 
2 1 5 par e nth e sis 2 1 6 bracket which expresses the unified nature of wait_for_cond(cond_3), 
end_wait_for_cond and the associated program sequence, up to the "synchronously 
clocked system level 2"). 2 1 Condition cond 3 is checked in the clock cycle of this 
system level to ascertain whether it has been satisfied. If cond_3 has been satisfied, the 
associated program sequence (here: the sequence of the commands pos5() and pos6()) is 
processed with the priority of the "synchronously clocked system level 2". The return 
from the "synchronously clocked system level 2" to the positioning command pos7(), 
ie. 218 ft to the "sequential user level", is indicated by the dashed 21 9 line arrow. 
[0053] The fact that, when the condition of the waitforcondition command has 

not been satisfied, the checking for the condition takes place in a high-priority 
"synchronously clocked system level" and, when the condition has been satisfied, an 
associated program sequence which can be created by the user is executed on this high- 
priority system level makes it possible for even extremely time-critical applications to be 
specified and carried out by simple language means. 
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[0054] One possible application is printed mark synchronization. The aim here is 

to detect a printed mark on a material with high priority. When this printed mark is 
detected, typically an actual value is captured ("latching" for example of a position or 
sensor actual value). On the basis of this captured actual value, a correction value is 
calculated and impressed on the system as a superposed movement. The process of 
actual value detection, correction value calculation and implementation of the superposed 
movement must take place in a deterministic time period. Therefore, this process must 
take place with high priority. 

[0055] A further application is the "rapid start of movement". Here, the aim is to 

detect, for example, an edge change very quickly and then begin a start of movement (for 
example positioning movement) immediately thereafter. The deterministics of detecting 
an event and triggering consequent actions are decisive for the productivity of a machine. 
In the case of production machines, such cyclical processes must take place in a 
deterministic time, for example <100 ms or <50 ms. When processing the tasks on a 
normal background level, these deterministics cannot be guaranteed. The mechanism 
described is particularly suitable for use in the case of machines which have periodic 
machine cycles. 

[0056] The performance is further enhanced by only inserting and considering 

currently applicable conditions when checking the conditions in the respective high- 
priority "synchronously clocked system levels". 

[0057] As already mentioned in 220 fiifwe 22 Connection with Fig. 6, the 

mechanism described here does not require an explicit event handler. 
222 ¥he 223 Conseauentlv. the great advantage from the user viewpoint is 224 oons e qu e ntly 
that the user can now formulate high-priority events in a sequential running program on a 
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relatively low priority level of a "motion task" in his program flow with the aid of 
program constructs, and does not have to change into another program which he then has 
to project by means of other mechanisms (for example manually or under interrupt 
control) onto a synchronous user task 225 . Instead. 22 W 27 lhe 228 «steed 229 iiser has the 
possibility in a closed user program of formulating this "waiting for high-priority event" 
and "high-priority reaction" cycle for this event in a program on a closed basis. 
[0058] The wait for condition command can be used by the user very flexibly 

and easily, since it is available as a normal programming-language construct. The 
formulation of the conditions is also flexible and easy for a user. For instance, for 
formulating these conditions, the user can use program variables from a user program or 
internal variables of the controller, or he can also reference process signals. These 
variables may then be combined logically, arithmetically or by any desired functions in 
terms of their content, to formulate a condition from them. 

[0059] The wait_for_condition construct provides a user with the possibility in 

normal user programs for sequences of movements of temporarily switching a user 
program to a higher priority level, to be able to guarantee deterministic processes. 
[0060] 230 Th e r e pr e sentation according to Figur e 231 Fip. 8 shows the 

programming-language construct of the wait for condition mechanism as a syntax 
diagram. The terminal elements are in this case represented with rounded corners: 
"WAITFORCONDITION", "WITH", "DO", "ENDWAITFORCONDITION" and ";". 
The non-terminal elements are represented as rectangles: "expression designation", 
"SWITCH" and "INSTRUCTION PART". The elements "WITH" and SWITCH" are 
optional. 
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[0061] 232 Tho representation according to Figuro 233 Eig, 9 shows the use of the 

waitforcondition construct in a program sequence. In the upper part of ^Figwe 235 !^ 
9, the formulation of the condition "my expression" is represented, in the lower part it is 
shown how this condition is used in a wait for condition construct. 
[0062] 236 Tho repr e sontation aooording to Figure 237 ^ 10 238 showo in 239 is a 

schematic representation 240 of^ej)ossibilities for 241 hew 242 fib^^g the basic clock 243 is 
ebtained-for the industrial controller. 244 FiguFe 245 Eig i 10 shows 246 * by way of example 247 , 
a communication topology into which the controller S is integrated. The controller S is 
represented by a square. The controller S is connected by a connection line A2 to the bus 
Bl, to which the external device EG is attached via a connection line Al. The connection 
to the technical process P2 takes place via the bus B2. The technical process P2 is 
represented at the lower edge of the figure by a rectangle. The controller S is connected 
via the connection line A3 to the bus B2, which in turn establishes the connection to the 
technical process P2 via the connection line A4. 

[0063] The generation for the basic clock of the controller S can take place from 

different clock sources. For example, from an internal clock source, represented by the 
internal timer T2 of the controller S or else by an external clock source, such as for 
example the timer Tl, which belongs to the external device EG. The basic clock of a 
communication medium may also serve, however, as an external clock source. If the bus 
B2 is realized for example by an equidistant Profibus, the clock for the controller can be 
obtained from the basic clock of this bus. This is represented in ^Sgwe 249 ^ 10 by the 
timer T3 being positioned directly on the connection line A3, and this connection line A3 
establishes the connection to the bus B2. The controller 250 §js consequently attached to 
the bus as a slave and can use the bus clock directly. Furthermore, a clock generator TG 
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which is integrated in the technical process P2 may serve as an external clock source. A 
clock generator TG in a technical process may be, for example, the operating cycle of a 
production machine or packaging machine. In the representation according to 
251 figm=e 252 Fig. 10, bus connections are represented by way of example as communication 
media. However, ring, star or other types of connection may also be chosen as 
communication media, as well as wireless connections. The basic clock mentioned above 
can then be derived from these connection systems. 
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WE CLAIM: 

253^254 15 A memo d of operating 255 a» 256 a programmed industrial 

257 * 25S * 259 t~ * 

controller equipped with a runtime system m^eatieuteg-for j| production maemnes; 
vdrefgstt-mgsh^^ comprising the steps of 

checking for occurrence of a 261 m@f4^wart 262 desired condition in 
the 263 pmgFMa4tew 264 oi^ration of the machine^ 

stopping the pr ogram flow of the machine operation while 
checking for 265 &Rv 266 the occurrence of said desired 267 ee»€&iea-eFeHp^ 

268 * * 

pf©gf«»H4lew-keHig4m^ pondition 
and 269 th©-pFegFam4tew^k©«^^ 

esti&Av^ for said condition to occur. 

increasing the priority of 271 ^checking for the 272 desired 
condition 273 bemg4flerease44ft-6®^ to the current task priority 

275j ^M^wai^gg4i^ 76 in the program flow, and 

immediately continuing the program flow upon satisfaction of the 
condition 277 -te-be-sa&sfied. 

278 2r- 279 16. The method according to claim 280 -b 281 JUL wherein once the 
condition has been satisfied, the following program sequence is processed with high 
priority up to an explicit end, the old task priority being resumed after the explicit end of 
the program sequence. 

282^283 17 The method accor( iing to claim 284 4t 285 1 5. wherein process 
signals and/or internal signals of the controller and/or variables from user programs are 



used for the formulation of the conditions. 
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286 4t- 287 1 8. The method according to claim 28 V 89 JJ» wherein the 
conditions contain logical and/or arithmetic and/or any desired functional combinational 
operations. 

290 £- 291 j&_The method according to claim 29 V 93 1S, wherein 29 V 95 thg 
user program for the operation of the controller 2% e6ntems 29 7 is capable of responding in 
the manner set forth more than one such 298 m e ohaniom 299 condition . 

3W 6r- 301 2Qjrhe method according to claim 30 V 03 !! wherein 304 -HHhe 
operation of th e controll e r, there 305 mflv-be 30 6 are provided for the controller, a plurality of 
user programs which contain th e s e m e ohanisms operate in the manner set forth . 

309^3io 21 The jnethod as claimed according to claim 31 V 12 15* wherein 
the 313 rospoctivQ mechanism 3 14 program for operating t h e controller is available 31 W 
us e r in a us e r program as a customary programming-language construct. 

316 St- 317 22. An industrial controller for carrying out the method according 
to claim 31 % 319 J^ wherein the runtime system of the controller contains a running level 
model which has a plurality of running levels of different types with different priority, 
320 th e following 321 said running levels 322 b e ing provid e d 323 comprising : 

a) a group of levels with synchronously clocked levels, comprising having at 
least one system level and at least one user level, 326 it being possibl e for the levels of this 
group of levels 327 to hav e prioritizing 328 being capable of being prioritized with respect to 
one another; 

b) a user level for system exceptions; 

c) a time-controlled user level; 
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d) an event-controlled user level; 

e) a sequential user level; and 

f) a cyclical user level; 329 

and wherein user levels of the group of levels a) 330 optionally being 33 W able to run 
synchronously in relation to one of the system levels of the group of levels a). 

332^333 23 The industr j a i controller according to claim 334 «; 335 22, wherein 
the basic clock of the running level model is derived from 336 anv one of an internal 
timer 337 or from 338 ^ an internal clock of a communication medium 339 or from 340 , an 
external device or 341 from a variable which belongs to the technological process 342 = gf^ 
machine . 

343 4©r- 344 24 t= The industrial controller according to claim 345 S; 346 22* 
wherein the time-controlled user level, the event-controlled user level, the sequential 
running level, the cyclical background level and the user level for system exceptions are 
optional. 

347 44r- 348 25. The industrial controller according to claim 349 « ; 350 22 ft 
wherein the synchronous levels are clocked in relation to the basic clock with a step-up 
and/or step-down ratio and/or in the ratio 1:1. 

351 43r- 352 26. The industrial controller according to claim 353 «/ 54 22* 
wherein further prioritizing stratifications are provided within the running levels. 

355-^356 27 The industrial controller according to claim 35 V 58 2L 
wherein user tasks can optionally be run through during system running-up and/or during 
system running-down. 
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361 o 362* 



359 44r- 360 28. The industrial controller according to claim 87 22* 
wherein user programs which, depending on the type of user level, are programmed in a 
cycle-oriented or sequential manner can be loaded into the user levels. 
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ABSTRACT OF THE DISCLOSURE 
Mechanisms for operating an industrial controller 363 (S>equipped with a 

runtime system 364 -(RTS), in particular for production machines, which enable a user to 

wait in the program flow for any desired condition are provided^SW^JQg program 

flow 367 be«g 368 is immediately continued when the condition is satisfied and the program 

flow 369 beffig 370 is stopped when the condition is not satisfied, until it is established that 

the condition has been satisfied 37 ^"Ijhs priority of the checking for the condition 

373 bek»g 374 ii increased in comparison with the current task priority while waiting for the 

condition to be satisfied. When the condition has been satisfied, a defined program 

sequence is processed with high priority up to an explicit end, the old task priority being 

resumed after the explicit end of the program sequence. 
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